The Java 2 Platform Standard Edition (J2SE) and the Java Development Kit (JDK) provide developers with access to a wide range of user interface (UI) and graphical user interface (GUI) components. The JDK provides flexibility and control over the appearance of UIs and GUIs.
Conventional graphics toolkits, such as the Abstract Windowing Toolkit (AWT), provide application programming interfaces (APIs) for applications. The Java Foundation Classes (JFC), also commonly referred to as “Swing” or the “Swing toolkit,” are a set of Java class libraries having components that build upon the AWT by providing additional UI and GUI components and services. The Swing toolkit incorporates the AWT and is included in the JDK and J2SE to provide a rich, extensible GUI component library. The Swing toolkit is implemented in the Java programming language, and enables building of applications with GUIs and graphics functionality that can run on any platform supporting the J2SE, such as Microsoft Windows, Linux, and Mac OS X.
The Swing toolkit includes categories of components: atomic controls, complex data components, text components, menu components, layout containers and top-level window components. Examples of Swing components include buttons, panels, listboxes and checkboxes. In addition to the new components, the Swing toolkit offers a customizable look and feel that allows the components to take on the appearance of various windowing systems, or their own unique look and feel. For instance, Swing allows applications to easily convert from a “Java look and feel” to a “Windows look and feel.” Developers have the ability to create their own look and feel for custom applications. Regardless of the desired look and feel, a consistent API can be maintained for the component. Thus, developers can code their application GUI once and run it in multiple look and feels.
Swing is not designed for multi-threading. Access to a Swing component or class has to occur from a single thread, specifically an event dispatch thread (EDT). Thus, once a Swing component has been realized (e.g., when the component's “paint” method has been called), all code that might affect or depend on the state of that component should be executed on the EDT. The EDT is responsible for processing all UI and GUI related events, such as user interactions (e.g., mouse clicks, key presses), notification of listeners of user input, and all painting and graphics including repainting dirty regions or updated areas. Essentially every instruction to change something or request something from the Swing component is executed as an event on the EDT.
The EDT handles many different events, as described above. At the EDT, all of the events or tasks are queued and processed sequentially. Problems can occur when too many events are queued. If one event takes a long time to process on the EDT, such as loading an HTML page, all of the other events in the queue will have to wait to be processed. This waiting or delay is undesirable. It is generally perceived as the entire UI and application itself being unresponsive, often referred to as “freezing” or “blocking.”
Conventional techniques for attempting to reduce freezing or blocking include two Swing utilities. These Swing utilities are java.awt.EventQueue.invokeLater, used for asynchronous method calls, and java.awt.EventQueue.invokeandWait for synchronous calls. However, the methods java.awt.EventQueue.invokeLater and java.awt.EventQueue.invokeandWait create runnable classes for every call to those methods. Each runnable class is executed as a separate event on the EDT. Creating new runnable classes for every call is computationally expensive, and often results in the same freezing or blocking problem described above when many runnable classes are passed to the EDT.
Efficient techniques are needed for accessing Swing components from outside of the EDT, including calling methods requiring execution of events on the EDT from outside of the EDT.